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Contributions and correspondence should be sent to: 


Robert Hassinger, Coordinator - 12 Bit SIG 


c/o DECUS MR2-3/E55 ..-or.. Liberty Mutual Research Center 
One Iron Way 71 Frankland Road 
Marlboro, MA 01752 Hopkinton, MA 01748 


DECUS/Europe contributions are solicited through: 


Lars Palmer 

DECUS/Europe 12 Bit SIG Newsletter Liaison 
Hassle 

Fack 

S-431 20 MOLNDAL 1 

SWEDEN 


(Please include reference to Newsletter number and page when inquiring about material 
published.) 


NEWSLETTER SUBMISSIONS 


The Newsletter is currently published bi-monthly in the odd months. The deadline for 
each issue is the last Friday of the preceding even numbered month. Submissions are 
accepted at all times and are normally used in the next issue to go to press 
regardless of date of receipt. The deadline for ready-to-use material for the next 
Newsletter is 26-October-79. Material requiring editing/re-typing should be in 
earlier. Ready-to-use material should use an area 7 inches (18 cm) wide by no more 
than 9 inches (23 cm) long on each page. It should be single spaced on white bond 
paper whenever possible and must be reasonably clean, legible and sufficiently dark 
for good photographic reproduction. 


Material submitted in machine readable form is particularly desirable because it can 
be edited and incorporated into the newsletter format more easily. Higher quality 
reproduction is also possible this way. Contact the editor (Bob Hassinger) for 
further details on acceptable media and formats if you plan to make a submission in 
machine readable form. 


>> ADDRESS UPDATE << 


Jim Crapuchettes has asked me to call attention to his new address and phone number 
given under the listing of the Steering Committee members. Please correct your files 
to reflect this change as it has been in effect for some time and some calls are not 
reaching him because the phone company is not giving his new number when you call. 


©1979, DECUS 
It is assumed that all articles submitted to the editor of this newsletter are with the authors’ permission to publish in any DECUS publication. 
The articles are the responsibility of the authors and, therefore, DECUS, Digital Equipment Corporation. and the editor assume no responsi- 
bility or liability for articles or information appearing in the document. 
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SIG COMMITTEES AND WORKING GROUPS 


Steering Committee: 


Robert Hassinger - address above —- (617) 435-3452 


Jim Crapuchettes Lee Nichols 

Menlo Computer Associates, Inc. E. I. Du Pont 

801 E. Charleston Rd. Suite F Experimental Station 

Palo Alto, Calif. 94303 Building 357 
Wilmington, DE 19898 

(415) 494-3170 (302) 772-3839 

Jonathan Lockwood Lawrence H, Eisenberg 

Harris Semiconductor 17141 Nance Street 

PO Box 883 Encino, California 91316 

Melbourne, FL 32901 

(305) 724-7542 M.S. 54-40 (213) 788-0354 


Special Steering Committee Advisors: 

Tom W. McIntyre Stan Rabinowitz 

Micro-8 Working Group and US Symposia Committee Representative 

Jonathan Lockwood - see above 

RTS-8 Working Group COS-310 Working Group 

Lee Nichols - see above Lawrence H. Eisenberg - see above 
Symposium Software Exchange Committee 


Send copies of software you wish to exchange at the next US Symposium to one of the 
following committee members for preparation: 


Earl T. Ellis, Jr. James Coryell 

USCG R & D Center 863 France 

Avery Pt. 

Groton, CT 06340 Simi Valley, CA 93065 
(203) 445-8501 Ext. 296 (805) 526-7478 


(FTS) 642-7274 Ext. 296 
FALL DECUS SYMPOSIUM 


This year's DECUS/US Fall Symposium will be held in San Diego on Monday, December 10 

thru Thursday, December 13 at the Town and Country Hotel complex. Our representative 
on the Symposia Planning Committee, Jonathan Lockwood reports the following items of 

particular interest to the 12-Bit user community: 


* 12-Bit Road Map Session to orient attendees to the symposium sessions and 
activities. 

* Short Notes Session to provide for brief presentations and informal question and 
answer format interchanges 
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Four papers in the traditional PDP-8 area 

Eight sessions in the Word Processing area 

Ten sessions in the COS-310/DIBOL area 

Seventeen papers and sessions scheduled by the TECO SIG crossing all CPU and 
operating system lines plus a poster paper 

* The traditional media conversion and software exchange including an effort to 
support COS-310 software exchange within the system this time. 


x kK OK x 


We expect to be discussing several topics of current interest such as: Where OS/8 is 
going, COS-310 Version 8.1 and the future, WPS Version 4 (i.e. WPS-200 system) and 
Version 5. A WPS Hints and Kinks session is also planned. In the TECO sessions there 
will be discussion of the submission of TECO-8 Version 7 and a suite of new TECO 
releases for PDP-11 and VAX to DECUS. Since OS/8 users are the only ones that have an 
officially DEC supported version of TECO available, and since TECO is by far the most 
portable editing tool available to 12-Bit users, these sessions should be of 
particular interest and importance to them. 


COMMENTARY — WHITHER THE 8 ? 


It seems to be time to review where the PDP-8 family is going. As you can see, in Ray 
Stimson's letter, Earl Ellis stired up some reactions at DEC with his reference to the 
"death" of the eight. Some of the new-comers at DEC are not aware that the eight was 
Supposed to be "dead" back in 1970 when the PDP-11/20 was announced. I doubt that 
many 12-Bit SIG members took Earl's comment in the same way as some of the DEC people. 
All the same, the shift of responsibility for new PDP-8 end user sales to the 
Traditional Products Group is significant to us. 


The current situation, as I understand it is this. The various current PDP-8 and 
DECstation 78 hardware is still in volume production and it is being marketed by 
several areas in DEC such as Word Processing, the DEC Stores and Traditional Products. 
Some of these areas are continuing to fund new hardware and software developments. 

The DECstation 78 and OS/78 are examples of this. It appears that Traditional 
Products is planing to do a limited amount of hardware work, principally aimed at 
packaging current products. The question of what and how much else they might do can 
be answered this way I think: Each of DEC's product lines is a "profit center". Each 
product line manager is expected to show a profit as if he was running a separate 
company. The money he brings in can be invested in new development or whatever else 
he feels will best meet that end. Traditional Products will be limited by the income 
its new and reconditioned 12-Bit business brings in. At the moment I do not think 
they contemplate having the income to support very much significant new development in 
the 12-Bit area. 


This style of organizition has served DEC very well judging by its continuing success 
in a very rapidly changing market thru an extraordinary exponential growth from a tiny 
company to a two billion dollar a year worldwide corporation. It does not seem to 
serve the interests of the existing user very well, however, when the equipment he 
uses passes its peak and starts down the back side of the growth curve. Since DEC 
built their machines so well, they hardly ever die, so somewhere, someone is still 
trying to use almost all the computers DEC ever made. These users still need new 
software development and many of them would buy new hardware if they could get it. 
Typically this demand has not produced enough new income to fund the new software work 
that is needed although there has been some success in the hardware area. 
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I spent an afternoon with Ray Stimson at his new facility in Nashua, New Hampshire, 
talking about these issues. He is very dedicated to promoting the Eights as well as 
many other products such as PDP-11/40, 45 and 55 as well as the long standing 
reconditioned equipment business. I believe he wants to do everything he can to 
promote the sale of eights to the end user market within the limitations I have 
outlined. His organization has the capability to be very responsive to your inquiries 
and inputs. It is "vertical" in the sense that he can handle his own order 
processing, customer contacts and even credit verification. I want to encourage the 
establishment of a dialog between the users and Ray's group. In his letter he gives 
his address and a toll-free number you can call. His organization is small enough 
that it can responded to your individual needs. If you have ideas for helping to 
promote the Eight family, let them know, Ray is looking for input. 


My own concern is with continued software development for existing users. The problem 
seems to be that as end user Eight sales fall off, there is less and less push (and 
funding) to maintain support for the older equipment. Naturaly, the path of least 
resistance is taken. This means that new software is developed without trying to keep 
it compatible with the old equipment. Frequently all that would be needed would be a 
formal commitment to make the effort. It has been very rare that this restriction 
would cause any more difficulty than having to check on the compatibility issues. DEC 
should formaly take the position that they will do their best to maintain such 
compatibility. They could use some unconventional techniques in this effort such as 
"good faith effort" rather than formal commitments, catagory C and DECUS releases and 
cooperation with users for the testing of software on configurations they can no 
longer support themselves (for example, no pre-OMNIBUS machine was available in the 
software development group so I tested BASIC V7 on my 8/I and found a couple of minor 
incompatibilities that kept it from working on that machine - the fix is trivial and 
if DEC incorporated it in the released version, the new BASIC will be available to the 
thousands of 8/Is that otherwise would not have been able to use it). Cooperative 
efforts with users who have developed software that would be valuable to many users 
has already been demonstrated to be a worthwhile source of enhancement that should 
also be continued. 


I think support of the long standing tradition of compatible software and continued 
portability of the vast backlog of existing software is vital enough to the overall 
health of all Eight products and DEC's overall image in the computer business that a 
much more determined effort in this area is justified. In particular, Traditional 
Products needs to become much more active in the area of interfacing with the software 
development groups to press for the commitment and effort needed and to provide them 
with the support they need such as information on the compatability issues and maybe 
some facilities for occasional testing on the older equipment. The other products 
lines must be willing to expend the effort to cooperate with these efforts, possibly 
even providing some support for the extra costs involved, realizing that in the long 
run it benefits all of DEC through an improved corporate image, a more satisfied user 
base that promotes the products by word of mouth, increases their potential markets 
(new hardware and software products can then be sold into existing installations), and 
it broadens the field of users who can contribute their efforts to the pool of user 
software. It is very interesting to note that over the years, many of the most 
prolific contributors have been ones who where in situations were they were restricted 
to using older equipment. 


If Traditional Products will get people working actively on this issue and if they are 
willing to make at least some funding available, I feel confident that on-going 
Support and development of software for the entire Eight family can be a reality. 
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LOWG LIVE THE PDP-3, SAYS TRADITIONAL PRODUCTS 


In July's issue of this newsletter, Earl Ellis surmised that DEC 
must think "The PDP-8 will die" because responsibility has been 
re-asSigned to the Traditional Products Group. For the record, 
only PDP-~8 End User products fall within the Traditional Products 
charter. And as for allowing the demise of this family of viable 
systems, nothing could be further from Digital's intent. On the 
contrary, we are re-emphasizing the PDP-8 with new resources, 
from enhanced service and support for existing PDP-8 to their 
continued manufacturing and engineering improvements (including 
both software and hardware). Our charter at Digital, in fact, is 
not to lay prior generation products to rest, but rather to 
refocus support, place new emphasis, upgrade and make them 
available to past, present and future customers in need of 
time-tested performance. 


In short, Traditional Products is closing the generation gap by 
continuing to manufacture and offer viable system performers, 
along with compatible add-ons and software to our customers. So, 
Earl and other DECUS members, know that we're solidly behind your 
present systems, no matter what generation. And we will be in 
1999, and in 2009. Know also that if you want to upgrade or 
expand your PDP~8, or migrate to a newer generation processor, 
you can with us. ‘New, fully warranted Traditional systems at 
modest prices, or like-new factory refurbished systems, also 
warranted. Whatever your pleasure, Traditional products is 
ready, willing and able to help. Just call us at 300-258-1723 
(in New Hampshire, 884-5736) - or better yet, please come visit 
and see the new emphasis and focus being given to the end user 
PDP-8 at the new Traditional Products 70,990 sq. foot facility in 
Southern New Hampshire. 


Submitted by Ray Stimson 
Marketing Manager 
Traditional Products 
Digital Equipment Corporation 


38/31/79 


DIGITAL EQUIPMENT CORPORATION, 248 MAIN DUNSTABLE ROAD, NASHUA, NEW HAMPSHIRE 03060 
(603) 889-8900 TWX: 710-228-1582 
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INPUTS FROM EARL ELLIS 


Earl T. Ellis (whose address and phone are given near the beginning of the Newsletter) 
submitted this item and the following articles on the Virtual 8 Users Group and Teco: 


"PLEASE submit software for swapping as soon as possible to me or Jim Coryell so that 
it can be processed prior to the symposium. It would be highly desirable if we could 
develop a description of all software available for all to have. I would hope that 
this would include those of you who plan to attend in December in San Diego. I have 
TD's, RXO1, RK8, TM8 and Paper Tape I can get RX02 and LINKtape processed. I can read 
RT11 floppies, DEC 6-bit and DSD, Dewar, Lynch, and van Zee 8-bit floppies and IBM 
EBCDIC 800 BPI Magtapes." 


The VIRTUAL 8 Users Group 

"At the New Orleans Spring Symposium, several users of virtual PDP8 software met and 
discussed current developments. (A similar meeting was scheduled for the European 
Symposium at Monte Carlo.) The term 'virtual' here means the ability for one PDP8 to 
support two or more "simultaneous" OS/8 environments. Systems represented were 
MULTI-8, ETOS, and MULTOS/8. Each supports the DEC RK8E, and the System Industries 
1.6 Megaword disks. No support for the RL8A is currently offered. ETOS and MULTI-8 
V7 require custom hardware. MULTOS/8 and earlier versions of MULTI-8 do not require 
custom hardware. The number of terminals (users) that these systems can handle runs 
from 4 with MULTOS/8 to 16 with ETOS. At the meeting Fred Brant, a MULTOS/8 user, 
represented MULTOS/8. William Van der Mark of DATAPLAN represented MULTI-8. Myron 
Congdon of QUODATA and Lance Albrecht, Carl Gifford and myself, all users, represented 
ETOS. 


"ETOS for the 8 could be compared to RSTS/E for the 11's, and was originally patterned 
after TOPS-10. It was developed to support many terminals protecting some or all 
against 'hostile' users. There are just under 200 ETOS installations worldwide since 
first offered in 1975. ETOS supports the System Industries 30/40 disk system with two 
12.8 Megaword disk drives (25.6 million words usable). Users report that the 30/40 
system is about one-third faster than the RK8E. QUODATA is currently into final 
testing of Version 5B and hopes to release it soon. ETOS gives the OS/8 user the 
ability to support many 0OS/8's with minimum, if any, support from 'experts'. All ETOS 
sites use the same save file (ETOS.SV) with little or no modification. The ETOS Disk 
Monitor uses 24 bit math (double precision), giving a limit of 2 to the 24th (almost 
16.8 million) OS/8 blocks on up to four logical devices (69 million OS/8 blocks, 17.5 
billion 12 bit words). ETOS RKO5's are not readable under OS/8 stand alone. COS-300 
V3.06 is supported, but not as well as OS/8. Simple patches exist to allow some users 
to log into COS and others into OS/8 automatically. 


"MULTI-8 is a parallel development of ETOS, which for the 8 is like RSX-11D for the 
11. Great attention has been paid to maintaining the ability to have a foreground 
task driven by the clock (such as a A/D) with multiple OS/8's existing in the 
background. Real-time tasks can be swapped in as needed on a page by page basis with 
the Relocatable Task Library. Real-time buffers can be allocated and deallocated 
giving superior perrformance on smaller systems. Individual system modification and 
customizing results in there being little likelihood of two systems having identical 
software. This implies there be an ‘expert' present to implement and maintain the 
system. The latest version has a hardware assist to improve the performance of the 
multiple OS/8's. MULTI-8's RKO5 disks are addressable by OS/8 stand alone. 
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"MULTOS/8 V1 allows 4 users, each user has his own disc area. It relies on a very 
friendly environment. It is written in PAGE8, not PAL, and this allows a lot of 
flexibility, such as support for the TM8E. Last month's 12-Bit Newsletter (July 1979 
Number 35) page 8 describes Version 2 as a vast improvement over Version 1. 


"Since the meeting in New Orleans, I have spoken with Jeff English. He's told me 
about his DUAL-OS which allows 2 0S/8's with RTS-8! This is a RTS8 V3 (MACREL) task 
that he's agreed to demonstrate at San Diego, if the proper equipment is available. 
DUAL-OS may be available through DECUS in the future. He said that DUAL-OS works best 
with one OS/8 in a compute mode and the other in a TTY Input/Output mode (i.e. Fortran 
crunching data and Editing a program). 


"I have also spoken to Jim Dempsey who has OMNI-8 running at 3 sites. Both COS-310 
and OS/8 are supported to about 4 active users in a 32K machine. OMNI-8 will run on 
pre-omnibus machines. It was tested on a PDP8/I. OMNI-8 does not use hardware assist 
or the MQ register. He plans to have it running on the KT8A and 128K before the end 
of 1979. It can run industrial control jobs using OS/8 Commercial Basic. OMNI-8 is 
running with the industrial controller UDC8/ICE. 


List of contacts: 


ETOS QUODATA Corp, 196 Trumbull Street, Hartford, CT 06103 
Thomas Schreier (203) 728-6777 

MULTI-8 WESTVRIES COMPUTER CONSULTING, Lekbandijk 11, 
4119 RA Ravenswaay, Holland 
Ernst Lopes Cardozo 011-31-03452-202 

(also LAB DATA SYSTEMS, 10320 Ravena Ave. Seatle, WA 

98125; Jim van Zee (206) 522-6950) 

MULTOS/8 COMPUTER METHODS CO. 7822 Oakledge Rd., Salt Lake City, 
UT 84121; Bill Haygood (801) 842-8000 

OMNI-8 NETWORK-SYSTEMS DESIGN, Inc., 640 Wisconsin St., Oshkosh, 
WI 54901; Jim Dempsey (414) 231-2432 


"If any of you have any information on these or other systems for the PDP-8, I would 
appreciate hearing from you. Please contact the originators for more information. I 
will act as a clearing house for information and edit information for the Newsletter." 


TECO 

"I have heard from Stan Rabinowitz. He has left his PDP-12 in Maynard and is now 
VAX'ing in Nashua, New Hampshire. He's looking for someone in the 12-Bit world to 
take over TECO for the PDP8. The current version is being submitted to DECUS in 
MACREL by Stan. I'11 distribute it until it is available from DECUS. This person 
would have to be most concerned with collecting TECO Macros, contribuing to the TECO 
SIG Newsletter, and representing PDP8 TECO at meetings where TECO is discussed. A 
good working knowledge of TECO is the prime requirement. I'm a SCROLL nut." 


QUERY FROM JIM VAN ZEE 
"Who is responsible for EDITX, FORTZ and the SABR random access R/W routines for 


FORTRAN II? I got a copy of these things via the 'grapevine' (they were available at 
the New Orleans DECUS meeting), and don't know who to credit." 
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Note: Jim and I are interested in this because these items are valuable and worthy of 
broader circulation, perhaps via DECUS if they are not considered proprietary. The 
information available at the Symposium was virtually non-existant. No identification 
of authors, no real documentation and no sources. I am particularly interested in 
EDITX which is a modified version of OS/8 EDIT with patches added to support lower 
case commands and scope mode rubouts. These make EDIT much more useful for things 
like text editing (for use with RUNOFF, for example) using modern upper/lower case 
terminals. Since no one at DEC seems to have any interest in EDIT beyond the fact 
that it is the only supported editor for OS/78 based systems, it seems as though the 
users will have to maintain and enhance it as has been done in this case. I find that 
if you do not have access to a viable cursor oriented CRT editor and are not 
interested in learning the complexities of regular TECO, OS/8 is still easy to learn 
and teach and with these enhancements, it works quite well, even on our rather slow 
DECstation 78. I hope that we can document the genealogy of EDITX and the other items 
so they can be made available in one way or another. 


Jim's address is Lab Data Systems, 10320 Ravenna Ave NE, Seattle, Washington 98125, 
phone (206) 522-6950. If you have any information, I would also like to hear about 
it. (RH) 


NOTE FROM JIM VAN ZEE 


"We recently received a new Data Systems Design model 440 dual-density floppy disk 
system for our 8/e. This unit is hardware and software compatible with the RX02 
(#32,p29), and as there have been several comments in recent newsletters on the 
upgrade from the RX01 to the RX02, I thought I might share a few of my experiences 
with this new system. 


"To begin with, the DSD-440 is very nicely designed. It has 2 Shugart drives in a 
low-profile (5-1/4 inch) chassis, with a sculptured appearance very reminiscent of the 
11/34. Both the price and the size (but not the performance!) are substantially 
smaller than the equivalent DEC unit. The 440 contains an 8085 microprocessor which 
is capable of performing some 20 different diagnostic tests completely independent of 
the host CPU. 


"The documentation is quite extensive (about 200 pages), but it is primarily PDP11 
oriented. For instance, one must ‘initialize' a standard disk before it can be used 
for double-density recording. Yet nowhere in this voluminous manual was there to be 
found a routine for doing so! I eventually dug out the information and wrote a little 
FPAL routine in U/W-FOCAL to initialize the disk so I could get a system up and 
running. Once past that step I discovered that the RXCOPY program distributed with 
the new OS/8 extension kit is now smart enough to take care of this matter if it has 
to, so the user who already has a double-density system disk can just use the DUP 
command to turn a standard floppy into a double density one. 


"Just what is ‘double density'? This phrase definately creates the impression of data 
bits squeezed twice as close together, with the obvious concern about decreased 
reliability, etc. (#32,p33). In fact, the actual number of 'flux transitions' - the om 
microscopic changes which are used to record the data - are the same in both single 
density (fm) and double density (mfm) recording. The only difference is how the data 

is encoded. This is not to imply that double density is automatically just as 

reliable, since the 'bit window’ in which a given transition must be judged is 

necessarily smaller which tends to magnify the effects of 'wow and flutter', but on 

the whole one would not expect great differences in the raw error rate between the two 
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recording methods. The 'bit density', incidentally, is remarkably high: greater than 
6000 fci on the inner tracks, compared to about 400 for good old reliable DECtape - 
hence the precautions about proper media care! 


"The result of the mfm encoding technique is that each sector can now hold 256 8-bit 
bytes rather than only 128. This fact is the basis for DEC's claim that the RxX02 
provides over a megabyte of storage (on two drives). However, this claim is at best 
misleading for the PDP8 user, since it turns out to be as near to impossible to use 
all of this storage as it is likely that there will ever be a major revision to 0S/8! 
In fact these two issues are somewhat related, since the major difficulty with double 
density recording is that the sector size on the floppy is not easily related to the 
OS/8 block size. On single density disks, 3 sectors = 1 block. On double density 
disks the ratio is 1.5 sectors/block, which means that files will necessarily begin 
and end in the middle of a sector and programs such as FOTP will certainly have to 
copy files in chunks which also begin and end between sector boundaries. Since the 
controller can only read and write complete sectors, this is an enormous difficulty 
which must be taken care of in the handler! 


"What is the resolution of this problem? The obvious solution is to put fewer bytes 
of data in each sector, so that one can regain the match between sectors and blocks. 
Both the RX01 and RX02 controllers thus have a special '12-bit' mode in which only 96 
(or 192) bytes are used in each sector, which corresponds to 64 (or 128) words. This 
is the mode in which all DEC (0OS/8) handlers operate. The RX01-based WP systems and 
COS-310, on the other hand, use '8-bit' mode, mapping 3 sectors into 1 OS/8-sized 
block. As indicated above, the use of 8-bit mode in double density would require 
dealing with fractional sector boundaries, which I think it is safe to say, is just 
simply impossible within the constraints of a normal handler. One could, of course 
write a -program- to do this sort of thing, so that one could utilize all of the disk 
for archival storage or something like that. But as delivered to the customer, the 
realizable storage on the RX02 is actually only 750 kb, rather than 1mb — hence the 
discrepancy between 'double density' and 'double the amount of storage' noted in 
newsletter #32, page 33. 


"This discovery all came as a bit of a surprise to me, since I have been using a 'byte 
mode' handler (#29,p15) on our DSD-210 (RX01 equivalent) system ever since we got it, 
and I had just assumed that I could rewrite it to get twice the storage. No way! 
Thus my friends who decided not to wait (and wait and wait) until DEC came along with 
double density, and who bought a Sykes or an AED or a Diablo system instead, have had 
the last laugh! I am particularly annoyed since the AED 6200 system which we 
evaluated well over two years ago provided 1771 blocks per side - 80% more than the 
RX02! The problem was that it couldn't read standard floppies, which I felt was an 
absolute necessity. Reportedly AED'S new controller can do this, which would make 
this a very attractive system. Even the Sykes double density system provides over 
1300 blocks, which one would expect for the usual soft-sectored format, although it 
cannot read standard floppies either. 


"Thus we decided to go with the DSD-440, which in conjunction with DEC's rather 
remarkable new handler can read either single- or double-density disks (in 12-bit 
mode!), determining on the fly which kind of disk has been inserted and making the 
appropriate adjustments for the number of Sectors/block, interlace factor, etc. This 
is completely transparent to the user, even to the extent that the new version of PIP 
ean correctly ZERO (or SQUISH) a disk known only as 'RXA1' - which could have either 
494 or 988 blocks on it! Since the 'device length' entry for the RX02 (location 13632 
in PIP) is zero, clearly PIP treats this as a special case, probably testing a 'magic' 
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location in the handler in order to know what to do. 


“Programmers who have written byte mode handlers for the RX01 will, no doubt, be 
pleased to learn that the RX02 is not program compatible with the RX01 in 8-bit mode. 
(it is, in 12-bit mode, except for the 'NOP' command, which undoubtedly made life easy 
for DEC!) Thus none of the existing byte-mode handlers will work on the RX02 without 
at least some modification, and to make them work interchangably with either 
controller requires roughly another 6-8 instructions, which could certainly put a 
Strain on an author's imagination in cases where the code is already tight! Since I 
suddenly found myself in need of just such a handler so I could read all my 
"byte-mode' disks on either system, I set out to see what could be done about this 
situation. 


"To make a long story short, I eventually came up with both a system and a non-system 
handler which will work with either controller, and which store data in a PDP-11 
compatible format, thereby greatly simplifying communication between these two 
machines. (I can directly copy files from a RT/11 floppy using U/W-FOCAL, for 
instance, and ASCII files written with this handler are directly readable under RT/11, 
although for best results they should be positioned on a PDP11 block boundary which 
occurs every 12 0S/8 blocks.) I am particularly excited about the system handler, 
since there was some speculation that it couldn't be written (#29,p15) - and it wasn't 
easy! System disks using this handler boot up with the standard bootstrap, so the 
only observable difference to the user is that s/he has a total of 667 blocks on a 
standard floppy and a 77% faster transfer rate! Other features are that the system 
handler supports both drives, thus freeing a scarce 'device slot' and the bootstrap 
preserves the system date (why doesn't DEC do this??). 


"IT had great hopes that this handler would work on all systems, just as DEC'S standard 
handler does; but unfortunately the 6100 microprocessor which is used in the DEC- and 
wordstation terminals is simply too slow to keep up with the higher data rate; The 
result is that only 1 sector is read per disk rotation, which makes data transfer 
impossibly slow. The only solution to this problem is to adopt a different data 
format, which I call 'VT/78' format, and which is not PDP-11 compatible. Using this 
format one can operate in byte-mode on the VT/78 with the same speed as the standard 
DEC handler, but with 40% more usable storage (611 blocks vs. 438)! This is 
especially important to those trying to run FORTRAN IV on an OS/78 system, but I think 
that almost everyone has had a need for more file space on their system disk! A 
modified version of these handlers is also available for use with Bill Haygood's 'huge 
floppies' (#33,p6), which provides an additional 103 blocks of storage (714 
blocks/side on a system disk: more storage than a dectape!). 


"To solve the problem of needing separate handlers for these two different formats, I 
added a 'switch' to the non-system handler so that it will work with either one. Thus 
one merely 'SET'S location '200' to 0 for PDP11 format, or to any non-zero value for 
'VT/78' format. It would be nice if the source file for SET were available, just as 
the source file for CCL is, so that one could easily implement a command such as 'SET 
D1: PDP11' INSTEAD OF 'SET D1: LOC 200,0'. I have also wanted to extend the SET 
command for use with the LQP handler so you could say 'SET LQP PITCH 10' or 'SET LQP 
MARGIN 5', instead of having to know just which locations to change. At any rate, 
people who are interested in further details about these new handlers should contact 
me at Lab Data Systems, 10320 Ravenna Ave. N.E., Seattle, WA 98125. 


"Here is a little survey of some of the better known floppy handlers which may be of 
interest. Others who have written such things, will, I hope, make their own 
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measurements and submit them so that the readers can better discern what is available. 
Timing measurements were made using FUTIL to simply scan from block 0 to the highest 
block available. This is a method which should be available to all, but which may 
penalize the handler by testing only single block transfers. Results are given in 
'OS/8 blocks per second' on an 8/e or 8/a, and on a 6100-based system. All handlers 
listed below -except- Dewar's and DSD'S are available as system handlers. Lynch's 
System handler (#34, p6) requires a special bootstrap, but is available in a ROM 
version for an 8k machine; The others all require at least 12k (except for the rx01 
handler). 


NAME AUTHOR BLOCKS 8E,A 6100 COMMENTS... 


RXO1 DEC (VER E) 494 1360 525% 12-BIT, SINGLE DENSITY 

DSDH DSD (ZEISS) 658 15.7 Cae COS-310 COMPATIBLE, ERROR MSGS 
RB8E LYNCH 666 8.5 1.8 231 TRACK CHANGES 

RX8 DEWAR 667 Tite 2.0 NO TRACK OFFSET, USES BSW 

RX11 VAN ZEE 667 23.0 2.0 PDP11 FORMAT, RX02 COMPATIBLE 

RX61 VAN ZEE 667 12.3 12.3 SPECIAL FORMAT, STANDARD BOOT 

RH8  HAYGOOD 770 1655 2e0 NEEDS SPECIALLY FORMATTED DISK 
RX02. DEC (ROOT?) 988 26.0 lee 12-BIT, DOUBLE (DUAL) DENSITY 


*This is an average figure. The first 130-140 blocks (23-25 tracks) are read much 
more rapidly (about 13 blocks/second), after which the rate suddenly decreases. This 
is probably the result of overhead in a single-block transfer. At any rate, this area 
usually contains things like CCL, DIRECT, etc., so the overall system performance is 
better than the number shown might indicate. 


"One final note: the new DECwriter IV (LA34) is well worth looking at; It is a 30 eps 
terminal which is really nicely designed (but doesn't have lower case descenders!). I 
was never very fond of the LA36 monster which I always felt was simply too gargantuan 
to be placed next to a decent-looking computer system. The LA34 is much more like an 
office typewriter (but with an inferior keyboard touch), yet it can still use wide 
‘computer paper' if that is what you like to feed it. Educational institutions 
belonging to something called 'EDUCOM' can order these things from National Computer 
Communications in Stamford, ct (phone: 800-243-9006) at a very reasonable price. 

Other items, such as A-J modems, as well as an LSI-11 based (TERAK) computer system, 
are also available to EDUCOM members at extraordinarily low prices. (modems from NCC, 
TERAK from the manufacturer.)" 


NOTE FROM JONATHAN VAUGHN 


"T am in the process of submitting some programs to DECUS. Here are the 
preliminary versions if anyone would care to field test them. There are two programs 
(TSSI and TSS10) which are for using a mini-computer under OS/8 communicating with a 
time sharing system. TEDIS is an overlay for the version of TECO that is released 
with OS/8 version 3C. At the end of execution of each editing command, TEDIS dumps the 
contents of the text buffer onto the cathode ray terminal with a pointer to the 
location of the current character position. Thus, the effect of each editing command 
can be seen immediately after it is executed. TEUL is an overlay for TECO that permits 
upper-case, lower-case text to be generated on a KSR 33. Before they get into DECUS 
I'll send out copies on receipt of an RX01 floppy and return postage. (By the way I 
have just gotten a DSD-210 floppy drive and it seems to work just as advertised.) 
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"I've seen a number of comments of people who have had trouble with FORTRAN IV 
using the BAT: input device handler. There is trouble as well, sometimes, when it is 
called it passes to the input buffer the string of characters in the BATCH input file 
between the current character and the next line that begins with a dollar sign. 


"If this character string is not as long as the input buffer it is padded with 
zeros, and it ultimately has a CONTROL-Z character appended to it to flag the end of 
file. In FORTRAN II, at least, if there is no input (that is, no characters precede 
the next line that begins with a dollar sign) the handler hangs up. Under other 
circumstances it seems to work all right. 


"One consequence of the way that the handler works is that it is impossible to 
read any less than the whole string of characters up to the dollar sign (which may be 
several lines), for obvious reasons. Now, in FORTRAN II (and perhaps FORTRAN IV, 
which I don't have) the input routines are line-oriented, and it would be much more 
convenient to have the BATCH handler operate in a way similar to the TTY: handler; 
that is, read one line of characters at a time and pad the rest of the buffer with 
zeros. There is a simple patch to make the BATCH handler work this way. In BUILD the 
command "$AL BAT, 14525334" will make the BATCH handler read a line at a time, filling 
out the rest of the buffer with zeros (note - this patch from OS-8 V3). The handler 
will still hang up if there is no input prior to the next line that begins with a 
dollar sign. When this change is implemented it is convenient to change the name of 
the handler as well by the command "NAME BAT=BT" so that there will be no confusion on“ 
over exactly how the handler is working. I have been using this modified handler with 
great success in FORTRAN II for some time now to read lists of file names that are to 
be analyzed in U/W FOCAL or FORTRAN programs from the BATCH stream. Each OPEN INPUT 
BT: command (or CALL IOPEN ('BT',0O) command in FORTRAN) sets up the input handler to 
read the next line of text. Since this contains the file name, another OPEN INPUT 
command is used to get the information from the file and once this is analyzed, a 
dummy file name, FINISH, is used to flag the end of the series of files names. If the 
BATCH handler were not modified it would not be possible to read one line from it and 
then open some other input device and return to the BATCH handler without losing 
characters. 


"The programs TERAC(5-8).MA are for reading and writing floppy disks for 
interchange between an 8/E and LSI-11. The 8/E is running OS/8 on DSD210'S, the 
LSI-11 is a TERAK running UCSD PASCAL. There is little difference between the PASCAL 
system and RT11 system (ignoring directory format,etc.). But there are differences in 
block size (0S/8: 384 12-bit words per block; PASCAL: 512 8-bit words per block and 
1024 8-bit words per editor buffer. These programs ignore the directory of the LSI-11 
system entirely and just refer to block numbers; so if the LSI-11 directory is 
manually adjusted so that a file is created to span the correct blocks, things work 
out. PASCAL on the TERAK offsets the sector by 6 sectors each track, while RT-11 does 
not. This is only a minor change in the disk-driving routine (TERACH.MU) however. 


"By the way, now that I have the DSD-200 drives I am in a position to copy back 
and forth between RX01 floppy discs and those recorded on the XEBEC XFD-208 system 
(which uses MEMOREX 651 discs). so, if there's anyone who has useful software stuck on -™\ 
the XEBEC discs I'll be glad to get it onto the RX01 dises for the OS/8 community." 


Jonathan's address is Department of Psychology, Hamilton College, Clinton, NY 13323. 
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HAVE YOU CONSIDERED RECONDITIONED EQUIPMENT FROM TPL? 


I am always amazed at how few people consider reconditioned equipment from DEC's 
Traditional Product Line. I have mentioned before how they completely referbished our 
PDP-8/I and made it eligible for a service contract for the first time after many 
years of no service or ECO's. A couple of recent purchases have demonstrated again 
some of the reasons it is worth checking with them when you are looking for hardware. 


We needed a KL8JA serial line interface, the DEC sales office quoted six months for a 
new one, the used computer companies had none but TPL quoted a reconditioned one for a 
better price with a much faster delivery. The KL will go on our maintenance contract 
when it is installed so the "reconditioned" aspect does not concern me and the price 
is nice but the best thing is the better delivery. I hear that OEMs are going to TPL 
when they can not get deliveries of new equipment fast enough. 


Another example was the purchase of a disk to expand our PDP-11. RKO7s are too 
expensive, RLO1s are nice but not big enough and I would rather wait for a double 
density version before getting into them anyway and expanding the existing RKO5 system 
with new drive(s) seemed out of the question when the price was compared to the RLs. 
The key to meeting the the short term part of our expansion need turned out to be 
another call to TPL in Nashua. I found that I could get a reconditioned RKOSF for a 
very attractive price with good delivery. The price was a good bit better than the 
one I got from a used computer company, the drive is automatically eligible for 
maintenance and comes with full documentation and the other factors mentioned above 
apply here, too. 


“TPL has a toll free number you can call for information and prices and they have set 


up a Streamlined method for expediting your order through the company. The number is: 
(800) 258-1728 (in New Hampshire call 884-5736). I have found that dealing direct 
with TPL is by far the most satisfactory way to handle this sort of thing - going 
through my salesman has been much less satisfactory. 


MATERIAL FROM ROBERT R. BIGELOW 


The following material was received from Robert R. Bigelow quite some time ago but I 
do not think it ever got into the newsletter. Sorry for the delay. "I would like to 
pass along a warning to users who are using the algorithm for comparing two signed 
values described in newsletter number 24 page 9. These tests are good only for signed 
numbers in the range of -1023 to +1023. In the table below I give three examples 
where the tests will fail. 
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Case 1 Case 2 Case 3 

Decimal Value of A + 2046 + 1025 + 0003 

Decimal Value of B - 0003 - 1024 —- 2046 

Octal Value of A 3776 2001 0003 

Octal Value of B 7775 6000 4002 

CLA CLL 0 0000 0 0000 O 0000 

TAB B 0 7775 0 6000 O 4002 

CML CMA IAC 1 0003 1 2000 1 3776 
TAD A (3776) (2001) (0003) 

1 4001 1 4001 1 4001 


"In all three cases A is greater than B, however the "SPA" used in "A .GE. B" test 
does not skip as it should. The simplest solution that I have found is to convert the 
Signed values to unsigned values by adding an Octal 4000 to each and then use the 
corresponding unsigned test." 


Mr. Bigelow also sent a copy of an SPR he submitted on DIFRMT VHA: 
"PROBLEM: With the following responses DTFRMT fails. 


DTA? 12 

DIRECT? MARK 

201 WORDS, 2702 BLOCKS. OK? (YES OR NO) 
YES 

SET SWITCH TO NORMAL 

END TAPE ERROR PHASE 2 


"If the user responds to DTA? with just one (1) unit number the tape is formatted but 
the OS/8 extended date word (location 07777) is destroyed. 

"CAUSE: The program builds a table of DECtape unit numbers ending with 7777. However, 
there is not enough space allocated for that table. 

"SOLUTION: Move the table to an area that can accommodate it." 


The following ODT patch was also included. It fixes this problem and makes O an 
acceptable response to DAT? It also updates to Version 4B. 


~-GET SYS: DTFRMT 
- ODT 

1010/6401 6402 
1035/1055 1054 
1636/1333 1332 
1661/1041 1332 
1732/0000 1733;0 
1763/1732 1765 
1765/7402 0;0;0;30;30;30;0;0;0 
mG 

~SAVE SYS: DTF RMT 


NOTE: LOCATION 1765 MAY NOT BE 7402 
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Mr. Bigelow's address is Union Carbide Corporation, Nuclear Division, P.O. Box Y, Oak 
Ridge, Tennessee 37830. 


NOTE ON 8 — 11 COMMUNICATIONS 


Dr.-Ing. Goetz Romahn writes: "First my congratulations on the 8th anniversary. 
Since I am reader from the very beginning, I know what a fine work you did all the 
time. 


"There was a seek for help in the #34 newsletter, referring to communications between 
8 to 11. 


"In the DECUS RSX-11 library you will find a package (DECUS 11-354) consisting of an 
OS/8 to FILES 11 converter, a PDP-8 DECtape reader and a PAL8 cross assembler (a 
FORTRAN compatible subroutine). 


"DECUS 11-364 is a PDP-8 to 11 source converter running under RT-11. 


"There is another point of interest for PDP-12 users: several years ago I submitted a 
DECtape reader handler for OS/8 to DECUS. J.v.Zee used this handler, as he writes, 
with mixed success. He reexamined my code and fixed some bugs. He also wrote a 
version which does not use the EAE nor alter the MQ regester. Since I have no longer 
the resources to submit a new version of my handler, I think this is the right way to 
make the problems (and their solutions) public. For details write to Jim van Zee, LAB 
DATA SYSTEMS, 10320 Ravenna Avenue N.E., Seattle, Washington 98125, USA. 


"(You are right Jim, the cycle time for the PDP-12 is fixed at 1.9 usec, and not 1.6 
usec aS some DOCs state." 


The address is Freie Universitaet, Psychiatr.-Neurol.Klinik, Platanenallee 23, D-1000 
BERLIN 19, GERMANY. 


FORTX — EXTENDED FORTRAN II 


I recently got a chance to review the writeup for FORTX. It is described as "an 
improved and extended version of OS/8 FORTRAN II". It was first announced in 
Newsletter #29. As I recall, it was made available on a test basis to those who were 
interested. After reviewing the writeup, I must say that FORTX seems to be a long 
overdue, and very welcome extension of OS/8 FORTRAN II. In addition to many of the 
language features of FORTRAN IV, other extensions such as "structured programming" 
constructs such as IF ... THEN ... ELSE, WHILE, and structured DO have been added. 

One of the features I like best is to be able to do Boolean operations on integers 
(i.e. you can say CHAR=CHAR .AND. 177B -— note the ability to generate octal 
constants). These features plus FORTRAN II's efficient native mode code for handling 
integer manipulations and the ability to include assembly language code in-line seem 
to add up to a very nice tool for many jobs. If a package to help get 8-bit ASCII in 
and out could be added, It would be very attractive indeed. I think we should be 
doing all we can to encourage the continued vitality of FORTRAN II and extensions such 
as this. DEC presently has little interest in it but I understand that software that 
uses it has been making up a very important part of the DECUS Program Library 
submissions. (Incidentally, I understand that the PDP-8 area had more submissions 
than any other last month 35% of all submissions —- and that FORTRAN II was the largest 
part of that group.) 
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If you want to know more, I suggest you contact the author, George Gonzalez, Hearing 
Research Laboratory, 2630 Universty Avenue, Minniapolis, Minnesota 55414. 


INF PAK NOTE 


Sally Swedine recently sent a note to say: "Having received my DECUS Spring Symposium 
Proceedings, I was disappointed to find my paper, "INFPAK — AN AFFORDABLE INFORMATION 
RETRIEVAL SYSTEM", was misfiled under "PDP-11 Software - Data Base" (p. 1085). While 
I have written to DECUS, I think the best way to let my fellow 12-bitters know about 
it is through our newsletter. It is definitely a PDP-8 based system. I am now using 
this paper as an introduction for new users since the manual gets technical pretty 
quickly. 


"IT don't know if I will make it to San Diego, but I intend to send this package 
(DECUS 8-859) and the companion statistical package (DECUS 8-902) to Earl Ellis. 
(Presumably for inclusion in the symposium software exchange - RH) Unfortunately, the 
documentation is too extensive to consider sending multiple copies out, so I must 
refer users to DECUS for manuals." 


Sally also notes that she had trouble at the last Symposium with the PDP-8a not being 
able to handle her certified DECtapes. Did anyone else have trouble like this and 
does anyone know what the problem was? If I can find out, I will try to do something 
about it in the future. 


Sally's address is Computer Laboratory, Veterans Administration Hospital, 4435 Beacon 
Avenue South, Seattle, Washington 98108. 


FORTRAN II BUG 


Dr. Peter Lemkin writes: "In debugging an OS/8 FORTRAN II program, I found an 
interesting bug in the I/O package supplied by DEC. The OOPEN(device,filename) 
subroutine saves the "address" of the device name rather than the actual device name 
after an internal lookup. This means that if the device name is changed after an 
OOPEN but before the OCLOSE, an IOER will occur! The following code if executed will 
illustrate this problem. 


PROGRAM JUNK1.FT 


TEST THE FORTRAN II I/O PACKAGE FOR POOP PROGRAMING 
PRACTICE OF SIDE AFFECTS ON THE DEVICE VARIABLE 
FOR THE OOPEN ROUTINE. 
RUN AS: 
~COMPILE JUNK1.FT 
-LOAD JUNK1/0/H/G 


MQAAAAAAANARAAN 


DEVICE=LPT 
CALL OOPEN(DEVICE, JUNK1) 
WRITE (4, 1234) 
1234 FORMAT ( THIS IS PROGRAM JUNK1) 
DEVICE=SYS 
CALL OCLOSE 
END 
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"The solution is to not use the DEVICE variable in between an OOPEN/OCLOSE sequence." 
Peter's address is NCI, DCDB, IPU, National Institutes of Health, bethesda, MD. 20014. 


MARKET FOR USED DISK PACKS 


Until I talked to Paul J. Campisano a few days ago, I had never heard of anyone who 
bought and sold used disk packs. He sent the following note: "As we discussed today 
a large portion of our business is the buying of all types of disk packs. The used 
packs are cleaned and tested and then repaired, cannibalized or rebuilt with the 
intent of reselling these packs. The value of each pack varies with a given demand 
and/or our inventory at any point in time. 


"In many cases disk packs users are not aware that their old packs have a value, but 
we will be glad to make an offer at any time." Paul's address is Time Brokers of New 
England, 1250 Washington Street, Norwood, MA 02062 - phone (617) 769-4060. 
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LAWRENCE H. EISENBERG 
COS-310 Working Group 
17141 Nance Street 
Encino, California 91316 
(213) 788-0354 


Having received some encouragement through the mailbag this past month, we are pleased 
to announce a_ continuation of the brilliant articles designed to help you to help 
yourself in connection with DIBOL programming. This month we will discuss the manner 
in which the SORT routine can be utilized where there is nominally insufficient space 
for all of the required scratch areas. (We are going to reserve our discussion on the 
use of printed messages during BATCH control, without the PLEASE command, until next 
issue, due to the number of other features being provided this month. (Besides, this 
author is going on vacation next month, and needs something to fall back on for the 
following issue! No, the truth doesn't hurt at all.) 


Of considerable interest to many readers will be the attached DATE PATCH for V 6.05, 
which adds eight years of life to that version. (More on this below.) 


Continuing with the cooperation from DEC's COS-310 personnel, we are also. printing 
PATCH PTO2 for VERSION 8.01. We have not, however, been advised as to whether a 
similar patch will be required for V_ 8.00. We hope to have this information before 
the next issue. 


CAUTION - WHEN 24-K BYTES REALLY MEANS 24-K WORDS (48-K BYTES) 


The COS-310 SYSTEM REFERENCE MANUALS (all versions), as well as the Monitor, itself, 
following a compilation, are misleading, at best, and downright wrong with respect to 
the meaning of just how much memory is required for operation of programs. 


Having just completed several programs, all designed to operate well within the range 
of a 32-K WORD memory system, we were quite disturbed to find that all references to 
"BYTES" generally were intended to mean "WORDS" (two bytes to a word). 


The following overhead features should be kept in mind for programming large DIBOL 
programs. The MONITOR requires 4-K WORDS (8-K BYTES) over and above the memory 
requirements of the running program. The LQP printer requires an additional 4-K WORDS 
for a buffer, the necessity of which challenges most logic. 


When a program is compiled without one of the non-print options, the last line of 
information presented includes the size of memory required for operation of the 
program, e.g., 16 K CORE REQUIRED. The clear implication from both the display and 
the Manuals is that 16 K BYTES is required -- ain't so, Charlie. 16-K WORDS (32-K 
BYTES) are required! Thus, the largest memory size for which a DIBOL program can be 
designed for a 16-K WORD system (e.g., all 78s) is 12-K if there is even the remotest 
possibility that an LQP will be used as the output printer. 


FASTER WPS TO COS CONVERSION PROGRAM 


Having been unable to receive any response from the WPS-8 people with respect to the 
lively rumored faster WPS to COS conversion programs in the WPS-8 hoppers, this author 
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decided to do it alone. We have written such a conversion program, which operates at 
least twice as fast as DEC's, and which can operate many times faster, depending upon 
the number of fields involved, their sizes, etc. Not only is our program much faster, 
but it is written in a logical manner with good tracking documentation in the source 
files. (Those of you who have read DEC's unsupported version of WPSCOS most certainly 
will appreciate this.) 


We are planning to submit the entire program to the DECUS LIBRARY, but are awaiting 
permission from DEC, as part of the program requires use of a portion of DEC's own 
program, which really can't be improved upon (but can always be changed enough to be 
published!!!). 


In the meantime, anyone wishing a copy of the program may receive it from this author 
by submitting an SASE, including your diskette. Listings, only, will be provided upon 
request, with an SASE. PLEASE NOTE: The program written by this office replaces 
COSFIX, which was written by DEC. It is necessary that you have WPSCOS (or that we 
recieve permission to release it) to operate the entire conversion. WPSCOS reads the 
Word Processing File and transfers it to a COS logical unit. COSFIX then converts the 
file, character by character, to a DIBOL file. (There are some changes in our 
program, which we felt involved unnecessary complications in the DEC program, such as 
our requiring a pre-structured source file, instead of making it optional, and default 
assignment of logical units for the conversion (with capability of assignment of the 
destination logical unit as an option at runtime), and a few other changes, all of 
which are documented. 


PUBLICATION OF THIS ARTICLE IN DEBUG 


In cooperation with the DEBUG SIG, this article is now being published on a _ regular 
basis in both the 12-BIT and DEBUG SIG NEWSLETTERS. While the DEBUG SIG involves a 
wider range of equipment users, many of its members are interested in COS-310 and 
WPS-8 and are users of 12-BIT equipment. We hope that they find these articles 
interesting, and invite their reference to the past several issues of the 12-BIT SIG 
Newsletter for prior articles on the hints and kinks of COS-310 and all PATCHES to 
Versions 8.00 and 8.01. 


WORD PROCESSING HINTS COLUMN 


Last issue we proposed a Word Processing Hints Column, and suggested that we would be 
able to provide some help with respect to WPS-8. We have a list of "how to's" that 
far exceeds our COS-310 efforts, but only if there is an expressed need. To date we 
have not received any response. We'll whet some appetites. One of our latest "dis— 
coveries" involves the use of the List Processing Feature to omit skipping a _ line 
where there is a desired variable on a line which may, or may not, be present in each 
case. A fair example would be with address groups, where there may, or may not, be a 
need for a title description on a second line (e.g., "President"), or there may or may 
not be a need for a "Suite No.", etc. We have a routine which, while simple, involves 
a little imagination, in order to avoid printing of blank lines in these cases. If an 
interest develops, we will print several of these hints, if not -- well, this article 
keeps us busy enough with COS-310! 
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DATE PATCH FOR VERSION 6.05 


We have received a remarkable, as well as timely, PATCH for Version 6.05, which allows 
the use of DATES after December 31, 1979. The need for this PATCH is one of the items 
which has been of the most interest among our readers. The submission of this PATCH 
illustrates the type of participation which many more of you could provide, in order 
to keep this column alive. We will publish patches, routines, ideas and concepts, and 
your input is essential! 


The PATCH (which is appended to this article, immediately preceding DEC's PT02 to 
VERSION 8.01) can only be run with the VERSION 6.05 PATCH utility. There are a few 
notes which we have discovered in using the PATCH, and we pass them on for your 
protection and consideration. 


1. This DATE PATCH is not supported by DEC. Therefore, your use of it is a matter 
which you will have to consider for yourselves. We don't, however, believe that use 
of the PATCH can in any way affect any of your DEC warranties or service agreements. 


2. We have applied the PATCH (on RXO1s) and found it to work for the dates indicated. 
We have found no "side effects" and are unaware of any defect. We have not, of 
course, tested it extensively, as we are utilizing VERSIONS 8.00 and 8.01, which have 
much to offer over earlier versions. We also have requested DEC to advise us of any 
problems with the DATE PATCH, but have had no response on that as of this writing. 


3. The DATE CHANGE is effective only for the period of 1 Jan 1980 through 31 DEC 1987 
and does not provide for any "spillover" for dates prior to 1980. 


4. Use of the PATCH will change DIRECTORY DATES by increasing all existing file dates 
by 12 years, which can be a problem for many installations. We are attempting to find 
a fix for this problem, but there is no indication that we will have one in time for 
expiration of the current date, which is December 31, 1979. 


5. Since the MONITOR must be PATCHed, there is no easy way to change over a large 
number of diskettes, tapes, etc. We would recommend the following procedures, which 
will involve the least danger of loss. (a) Note that the PATCH uses angle brackets 
(<nnnn>) to indicate operator response —- use care]; (b) Use the PATCH to create a 
new Version 6.05D master to include the new MONITOR and the new Utilities (COMP, CREF, 
and DFDIR); (c) Create a new Device using SYSGEN/C, responding to the commands as 
with any new device; (d) Use PIP/C (V 6.05) to copy an existing device over to the 
new device (e.g., an existing diskette over to the new diskette); (e) Use PIP/Vto 
transfer COMP and/or DFDIR from the new MASTER if either is required. 


6. Use of the procedures outlined in Paragraph 5 will eliminate the need to perform 
more than one PATCH. The PIP/C option does not transfer the MONITOR, but will trans- 
fer all other programs and files and will not destroy the MONITOR. This also will 
provide you with your original device (e.g., diskette, tape, etc.) in an undisturbed 
state as a backup in case of any errors in procedures. 


We are most anxious to provide credit for this submission, as the individual who went 
to all the work is most deserving of the gratitude of many of you out there. However, 
we are presently awaiting permission to do so. (Please, when making any submissions, 
advise us that we may publish the source of the information, or ask us to withhold 
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that information. As a news publication, this author can withhold the identity of any 
sources of information, and will do so if requested.) 


We hope that the DATE PATCH will be of help to many of you. However, we would 
encourage you all to consider VERSION 800 (or 801) as being quite superior in most 
respects. Perhaps the only valid reservation is the fact that VERSION 8.00 does not 
support the negative number assignments to the LQP printer, which did allow’ for 
printing of lower case characters, among other things. 


HOW TO SORT A FILE WHICH IS TOO LONG TO SORT 


Our announcement in the last issue of a method for sorting files which take up too 
much room on a device, for use of the SORT program, received considerable interest, 
and did invoke several responses by mail and telephone. Accordingly, we discuss the 
procedure here. (Actually, the Manual does hint at this procedure, but some examples 
certainly would have been a help.) 


The procedure is fairly simple. It consists of ascertaining the sort fields, 
determining how much these fields can be reduced (see discussion) and ascertaining the 
record number on a new record. We will provide an example using an address file, 


consisting of seven fields of 45 characters per field: 


100 START/T 


300 RECORD ADDRES; MASTER ADDRESS GROUP RECORD 

310 LINE, 7TA45; SEVEN LINES, 45 CHARS PER LINE 

320 RECORD ADDSRT; RECORD FOR SORTING ADDRESS FILES 

330 LASNAM, Al2; SORT KEY 1 

340 CITY, A112; SORT KEY 2 

350 ADDREC, D5; ADDRES RECORD NUMBER 

360 RECORD 

370 RECNR, D 5; NEW RECORD NUMBER (REDO PROGRAM) 


In the above example, assume that of RECORD ADDRESS, the following assignments are 
made: 

LINE(1) = LAST NAME OR OTHER !D 

LINE (2) THROUGH LINE (6) = ADDRESS | NFORMAT ION 

LINE(7) = CITY/STATE/ZIP 


At this point you will note that RECORD ADDRES contains 315 characters for each 
record; RECORD ADDSRT contains 29 characters per record (which can be reduced even 
further, depending upon the range of accuracy required). As a_ general rule, 12 
characters is sufficient to sort the vast majority of full name lists (not for a 
telephone directory, but for employee, customer and similar lists). 


Regardless of the mass storage device being utilized, the routines described here will 
enable the use of SORT, even if the entire device is ALMOST full on a 2-diskette 
system, or completely full on a 4-diskette system, provided that there are at least 
two such storage devices available. (On a 2-diskette system, at least eight segments 
must be reserved for the MONITOR, the SORT command file, the SORT utility and the 
conversion program.) The examples provided assume that the mass storage is RXO1 and 
that there are only two drives available. (Needless to say, if additional drives are 
available, the procedures may be modified to avoid removal and insertion of different 
diskettes, although the program, itself, does not require changing diskettes.) 
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DEC's SORT requires the availability of not less than three work storage areas of at 
least the same size as the actual file. Even on a 4-diskette system, if one of the 
diskettes is entirely full, the file cannot be sorted without some modification, as 
there is not sufficient work space to complete the SORT. 


NOTE: Even with the following procedures, in a 2-Diskette system, it is not possible 
to SORT a completely full (i.e., 41 segments) diskette in a single pass. It can be 
accomplished in two passes, however, by writing an additional program to remove, e€.8., 
all names from A-K and then all names from L-M. This is somewhat more complicated and 
is beyond the scope of this discussion. If there is any need out there for assistance 
on the subject, please ask and we'll explain further. In the meantime, the largest 
possible area which can be SORTed in a single pass, on a 2-DISKETTE system, is 33 
segments. This only can be accomplished if an absolute minimum of program material is 
stored on the SYSTEM DISKETTE (e.g., MONITOR, DFU, SORT, cmndfl, programs (2)). While 
there are ways to increase the available size to about 38 segments, they may involve 
more trouble than using two passes. 


In the above example, we have reduced the required work area (as set forth in RECORD 
ADDSRT) to less than 10% of that which would have been required if the entire ADDRES 
file should be required. It is utilized as follows: 


1. Assign your logical units. (Assume RXi, 33; RX1, 4; RXO, 4; RXO, 4; RXO, 4; RXO, 

4; RX0, 4.) You must avoid assigning too large an area to your SYSTEM DISKETTE. In 
the above example, the largest area which can be required is less than 13% of the 
available 33 segments, so that 4 segments per logical unit assignment will adequately 
provide all the space required for the SORT CONVERT program, and the actual SORT on 
five logical units as work areas. BE SURE THAT YOU DO NOT EXCEED THE AVAILABLE 
SPACE ON YOUR SYSTEM DISKETTE. In some cases, it may be necessary to perform the 
sort on a special diskette containing only the conversion program, SORT and_ the 
MONITOR. In the example, above, less than 1/2 of the diskette is required to sort the 
entire file on RX1. 


2. Using the above record sections, write a short CONVRT program to secure your keys 
in the abbreviated form, and to ascertain the record number for each file: 


500 PROC 2 

510 C100, ; ADDRESS SORT CONVERSION ROUTINE 

520 ADDREC= 00000; CLEAR RECORD COUNTER 

530 INIT(1,IN,"“ADRES',1); INITIALIZE ADDRESS RECORD FILE ON RX1 

540 INIT(2,OUT,'ADSRT!,2); INITIALIZE SORT RECORD FILE ON RX1 

550 C110, ; START LOOP 

560 XMIT(1,ADDRES,EC110); GET ADDRESS RECORD UNTIL END OF FILE (EC110) 
570 INCR ADDREC; SET RECORD COUNTER TO CURRENT RECORD NUMBER 
580 LASNAM=LINE (1); GET KEY 1 -- LAST OR ID NAME 

590 CITY=LINE(7); GET KEY 2 (ASSUMES CITY ALWAYS ON LINE(7)) 

600 XM1T(2,ADDSRT); FILE THE ABBREVIATED KEY WITH MASTER RECORD NUMBER 
610 GOTO C110; RESUME THE LOOP 

620 EC110,; END OF PROGRAM - CLOSE FILES 

630 FINI(1) 

640 FINI (2) 

650 STOP 
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3. At this point, having compiled and run the above program, the entire "ADDRES" file 
is now reduced to less than 13% of its original size and ready for sorting. The 
following SORT command file is used to run the SORT: 


100 DEFINE 
110 Fl, A12; LASNAM 

120 F2, A12; CITY 

130 F3, D5; THE RECORD NUMBER - NOT TO BE SORTED 

140 INPUT ADDSRT/2; FILE TO BE SORTED, RESIDES ON LOGICAL UNIT 2 

150 SORT 5/3,4,5,6, 7; ASSIGN THE FIVE WORK UNITS FOR THE SORT 

160 KEY F1,F2; SORT ON NAME FIRST, THEN ON CITY 

170 OUTPUT ADDSRT/2; OVERWRITE ADDSRT WITH SORTED ABBREVIATED FILE 
180 END 


4. The above SORT command file is written on the SYSTEM DISKETTE and, at runtime, the 
ADDSRT file is sorted with the command: RUN SORT, cmndfl. Upon completion, the file 
ADRSRT will contain the sorted abbreviated records. It is now necessary to recon- 
struct the original ADDRES file. This is done by use of another short program (which 

we call ADREDO) and a re-assignment of the logical units. Assign the logical units, 

with the above example: RX1, 33 (ADDRES FILE); RX1, 4 (SORTED -- destination —- 
SHORT FILE); RX0, 33 (NEW TEMPORARY ADDRESS FILE ON SYSTEM DISKETTE). Using the 
RECORD SECTION described above, the following program will finish the SORT: 


100 PROC 3 

110 A DDREC=00000; 

120 INIT(1,UP,,ADRES',1); THE UNSORTED FILE ON RX1 

130 INIT(2,IN,|ADSRT',2); THE SORTED "SHORT" FILE 

140 INIT(3,UP,|ADRESX',3);. NEW SORTED FILE (TEMPORARY) ON RXO 

150 R100, ; START READ/WRITE LOOP 

160 INCR RECNR; GET NEXT RECORD NUMBER 

170 XMIT(2,AD DSRT,ER100); GET SORTED ABBREVIATED RECORDS TO END OF FILE 
180 ON ERROR R110; AVOID CRASH - SHOULDN'T HAPPEN, BUT ? 

190 READ(1,ADDRES,ADDREC); READ EACH ORIGINAL RECORD IN SORTED ORDER 
200 WRITE(3,ADDRES,RECNR); WRITE EACH RECORD IN SORTED ORDER 

210 GOTO R100; RESUME THE LOOP 

220 R110; 

230 DISPLAY(1,1,1); CLEAR SCREEN 

240 DISPLAY (5,10,'THERE 1S AN ERROR IN THE RECORD NUMBER FOR THE!) 

250 DISPLA Y(6,10,,ACCOUNT NAME OF:!) 

260 DISPLAY (6,28,LASNAM); DISPLAY THE PROBLEM ACCOUNT 

270 DISPLAY(8,10,1PROGRAM WILL NOW TERMINATE!'); ADVISE OF TERMINATION 
280 ER100, 

290 FINI(1) 

300 FINI(2) 

320 FINI(3) 

330 STOP 


5. Having compiled and run ADREDO, above, the fully sorted file resides on RX0O. If 
you are sure of your program, then you can add a step to the above program which 
merely will transfer the file from RXO to RX1, or you can accomplish the same thing 
with PIP, OPTION D. 
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6 We do embellish our program with screen displays to show the record number which 


is being worked upon, and the stage of the program, so that the operator will have 
visual confirmation of the program operation. Further enhancements in our own 
programs include the elimination of records which have been "deleted" (we use a _ blank 
for LINE(1) to indicate a deleted record) and elimination of indexi which will be 


superseded upon the creation of a new index on the newly sorted file. 
CALL FOR PROGRAM HINTS 


In the last issue we did emphasize our need for participation on your part to help 
keep the Newsletter alive. The response was encouraging. Now, we are going to be 
somewhat specific. In about two issues, we would like to present a fairly extensive 
review of the use of INDEXES (indexi?) with DIBOL programs. We have seen many dif- 
ferent approaches, and many seem to be fine for their particular application. A 
review of the various concepts, and their applications, might be of interest to many 
of the readers. Your participation is invited and your cooperation in sending us some 
of your ideas and applications will be appreciated and will aid in this project. 


By INDEXES, of course, we are referring to the manner in which specific records from a 
file are accessed. The creation and use of INDEXES for such purposes often times 
involves considerable thought and development for maximum utilization. Among. the 
various considerations are those of {a) where should the index (or indexes) reside; 
(b) how should the index be modified under program control, if at all; (c) how should 
the index be created in the first place. 


The solutions suggested in Appendix D of the COS-310 Reference Manual, while helpful, 
are not really as efficient as they might be and, to a large extent, depend upon the 
presence of sorted files. 


Please send your ideas and solutions so we may include them in our article in the 
future. Thank you. 


PATCHES 


Two PATCHES are presented in this issue: (1) DATE PATCH to Version 6.05 (discussed 
above) and PT02 to VERSION 8.01. The PTO2 (V8.01) PATCH solves a problem associated 
with some operating characteristic differences among various RX0O1 drives. The 
specific problem involves an inability to access drives 2 and 3 with RX0O1_ handler 
provided on VERSION 8.01. (We have not tried this PATCH with VERSION 8.00 and, since 
we have not experienced the problem which is being cured, are unable to state at this 
time whether it is required for VERSION 8.00.) The PATCH is to SYSGEN and will 
correct the problem. IT ALSO CHANGES THE VERSION NUMBER OF SYSGEN TO V8.01B. 


After the PATCH is installed, it is necessary to RUN SYSGEN/C to install the modified 
RX HANDLER in the MONITOR. 


wt. BO 122 
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NUM 
;COS 318 V 6.65 P 
;PATCH ALLOWS DATE ENTRY 1ST JANUARY 19808 -31ST DECEMBER 1987 


SEPTEMBER 1979 


ATCH TO DATE 


7;ALSO UPDATES VERSION NUMBER TO 6.905D 


7;ALL OPERATOR ENTRY'S ARE 
<R PATCH (CR)> 


COS PATCH SYSTEM VERSION 6.05 


FILE NAME: <COMP> 
BLOCK: <14> 
LOCATION: <164> 

OLD VALUE: 8132 

NEW VALUE: <8126> 
LOCATION: <172> 

OLD VALUE: 2381 

NEW VALUE: <2101> 
LOCATION: <END> 
RELATIVE CHECKSUM: <7574> 
NEW BLOCK PATCHED OK 
BLOC K: <2> 
LOCATION: <211> 

OLD VALUE: 163@ 

NEW VALUE: <1631> 
LOCATION: <END> 
RELATIVE CHECKSUM: <1> 
NEW BLOCK PATCHED OK 
BLOCK: <END> 

@2 BLOCK(S) PATCHED IN THIS FILE 
FILE NAME: <CREF> 
BLOCK: <4> 
LOCATION: <376> 

OLD VALUE: 1639 

NEW VALUE: <1631> 
LOCATION: <END> 
RELATIVE CHECKSUM: <1l> 
NEW BLOCK PATCHED OK 
BLOC K: <6> 
LOCATION: <161> 

OLD VALUE: 0132 

NEW VALUE: <8@126> 
LOCATION: <171> 

OLD VALUE: 2301 

NEW VALUE: <2101> 
LOCATION: <END> 


RELATIVE CHECKSUM 


<7574> 


NEW BLOCK PATCHED OK 


BLOCK: <END> 

62 BLOCK(S) PATCHED IN THIS FILE 
FILE NAME: <DFDIR> 

BLOCK: <2 

LOCATION: «144> 

OLD VALUE: 0118 

NEW VALUE: <8120> 

LOCATION : <END> 

RELATIVE CHECKSUM <18> 


NEW BLOCK PATCHED OK 


BLOCK: 


<END> 


81 BLOCK(S) PATCHED IN THIS FILE 
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FILE NAME: <CR> 
PATCHING MONITOR 
BLOCK: <14> 
LOCATION: <143> 
OLD VALUE: 5567 
NEW VALUE: <557@> 
LOCATION: <371> 
OLD VALUE: 6206 
NEW VALUE: <60809> 
LOCATION: <END> 
RELATIVE CHECKSUM: <7601> 
NEW BLOCK PATCHED OK 
BLOCK: <15> 
LOCATION: <110> 
OLD VALUE: 5567 
NEW VALUE: <55708> 
LOCATION: <END> 
RELATIVE CHECKSUM: <1> 
NEW BLOCK PATCHED OK 
BLOCK: <16> 
LOCATION: <372> 
OLD VALUE: 7668 
NEW VALUE: <7650> 
LOCATION: <END> 
RELATIVE CHECKSUM <7778> 
NEW BLOCK PATCHED OK 
BLOCK: <36> 
LOCATION: <375> 
OLD VALUE: 91190 
NEW VALUE: <8120> 
LOCATION: <END> 
RELATIVE CHECKSUM: <1@> 


NEW BLOCK PATCHED OK 


BLOCK: <27> 

LOCATION: <153> 

OLD VALUE: 8000 ;ONLY IF NO LETTER AT END OF 6.865 
NEW VALUE: <4500> 7COS CODES FOR 'D' & ! ! 

RELATIVE CHECKSUM: <4500> 

NEW BLOCK PATCHED OK 

BLOCK: <END> 

85 BLOCK(S) PATCHED IN THIS FILE 

FILE NAME: <END> 

EXIT 


COS MONITOR 6.95D 
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8 Digital Software News, August - September 1979 
COS-310 V8.O1A 
(PATCH 2) Seq 2 M 


2 of 4 


), Create a PATCH command file (PT02) using the following editor 
commands : 
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COS-310 VB.O1A 
(PATCH 2) Seq 2 M 


3 of 4 
-9480 5746 


.0490 END 
.0500 0025 
-0510 20 
-0520 314 
-0530 2243 
-0540 END 
-0550 0001 
-0560 END 
.0570 /*% 
0580 <ctrl/z> 
-WR PTO2 


2. Check the PT02 command file by running PATCH without the /C 
option. PATCH simulates the patching operation but does not change 
the file on the system device. When run without the /C option, PATCH 
displays CHECKSUM CORRECT—USE OPTION C TO UPDATE rather than NEW 
BLOCK PATCHED OK. To check the command file enter the following: 


«R PATCH, PTO2 


PATCH will respond by displaying the PATCH dialogue and returning to 
the Monitor. If PATCH does not return to the Monitor, check the PT02 
command file to insure that it was entered correctly. 


3. Install the patch by entering the following command: 


-R PATCH, PTO2/C 


PATCH will respond by displaying the PATCH dialogue and returning to 
the Monitor. 
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rT OoOMPU TER METHODS 
73822 Nakledge Raad 
Salt Lake Citr, UT 84121 


fus.20, 1979 


Mr. Robert Hassinger, Coordinator 
12-Bit SIG 

Liberty Mutual Research Center 

71 Frankland Road 

Hopkinton, MA 01748 


Dear Bob: 


“Here are some additional items on flopries which rou may find interesting. Please feel free to use anything 
may wish in the Newsletter. 


While Gary Coleman correctly points out the failings of single-sided floppies (the “write throush’ problem, 
etc), these problems do not plague the reversible flopries which I use for my “HUGE’ flopey. These “flippies’ 
are guaranteed by their manufacturers to be as 900d on one Side as on the other. The manufacturers have even 
Punched an index hole for reverse side use. Gary’s statement that ‘floppies are coated masnetically and 
formatted on both sides’ is only partially true. I have vet to find a single-sided florry that is formatted on 
the reverse side. 


Some additional points of interest concernins the IBM formatted florry and the RXO1: The IBM formatted 
floppies have 26 sectors on each track. I discovered recently that the 246 sectors are not evenly spaced on the 
track! Although everyone else may be aware of that, this came as a surerise to me. I made some tests using my 
AED floppy disk drive and discovered that while the inter-sector saps that exist between sectors 1 and 26 are 
each the same size, the inter-sector gap between sector 24 and sector 1 is considerably larger. In fact, it is 
large enough to hold three additional! sectors while keeping approximately the same inter-sector sap Size as 
before. Since each IBM formatted floppy track begins with sector 1 as the first sector after the index hole, I 
concluded that the larse gap between sector 26 and sector 1 must be to allow flopry disk drives to change 
tracks in time to catch sector 1 on the next track. The RXO1 is not sufficiently fast in track switching to do 
this--it just misses sector 1! and aust wait a full revolution. Jim Van Zee informs me that his DSD440 wil! 
switch in time to catch sector 1 on the next track and as a result requires only two revolutions per track 
instead of three to read the entire track. For DSD440 users, this results in a time savings of 33% over the 
RX01. 


Another point that Jim and I worked out is this: we discovered that the RXO1 will write ‘HUGE’ diskettes 
formatted with a 2:1 sector interleave only by takins a full revolution to write each sector. However, it will 
read the same 22:1 interleaved diskette with no trouble at all (the read speed is 26.9 OS/8 blocks per second). 
This is the reason for the 351 interleave on my “HUGE’ floppies. Jim sussested that after a write operation, 
there is probably a time delay before the head is allowed te read-- and that time delay is sufficient to cause 
the next accessed sector header to be missed (necessitating a full disk revolution). Among the implications of 
the above is that when one decides to write an OS/S floppy diskette handler, his timing considerations must 
take into account that each sector is actually only about 1/29th revolution rather than the more logical] (7?) 
1/26th revolution. This simply means there is less time to load/unload the floppy sector buffer than one might 
be lead to believe. , 
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Jim mentioned that he sent you some timing information on various flopry formats. Here are some that I have 
compiled also (all single density and speed is given in OS/8 blocks per second read/write): 


Nane Author Blocks Speed Comments 

RX01 DEC 494 13.0 12-bit 

RX8 Dewar 667 17.3 8-bit 

RH8 Haygood 770 18.6 S8-bit, 30 sectors/track, 351 interlace 
The following will run only on the AED 3100P floppy disk drive: 

AGF Hay300d = 9724 32.0 12 384-byte sectors/track, 221 interlace 

AGS Haygood 847 31.9 11 384-byte sectors/track, no interlace 


For those readers interested in vastly increasing their floppy storage, I will gladly supply information on 
the ‘HUGE’ flopry handler as well as on the handlers for the AED 3100P florey disk drive. The AGF handler is 
named the ‘Gigantic’ floppy and the AGS is named the “Giant Speedy’ floppy (with tongue-in-cheek, of course, 
as with the ‘HUGE’ floppy). 


Perhaps some of the above might be interesting to Newsletter readers: Bob. From the Rocky Mountain West, I 
send my best wishes to you and your family. 


Sincerely, 


ss ae 
SS ; at 

: ee, 
sf ee ta 


W. F. HAYGOOD, RR. 
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